fix(lint,metadata-protocol): a junk entry in stack.objects no longer crashes the reference-integrity seam, and a throwing probe rule is reported (#15494) - #15562

Fixes #15494

indexObjectGraph is the first statement of every rule that resolves a field path, and its local asArray returned an array unchanged — so a null member of stack.objects reached strName(obj.name) and threw before any rule's own per-object guard could run. One guard at the shared seam, and the whole family inherits it.

The decision this card asked for: SKIPPED, not reported

A non-record entry is silently dropped. Three independent readings pointed the same way, and the third is a measurement rather than an argument:

1. The siblings already answer it. Every asArray copy in @objectstack/lint that spells the defensive read at all drops the member and says nothing — validate-nav-target-refs.ts, validate-flow-node-writes.ts, validate-hook-body-writes.ts, validate-page-visualization-bindings.ts, validate-readonly-action-writes.ts, validate-rule-compilability.ts, validate-view-page-refs.ts and the rest. Not one emits a finding. The seam was the outlier, not the reporters.
2. Each member of the family already answers it three lines below the call, with if (!isRec(obj)) continue in its own per-object loop. A report from the seam would contradict the guard the same rule is about to run.
3. The raw lint path, measured. Driving the whole AUTHORING_RULES table (42 rules) over { objects: [null, validObject] }: 28 rules judge it in silence, 13 throw, and 0 report the junk entry. The one rule that reports anything is validateSecurityPosture with security-owd-unset, and its path moves from objects[1].sharingModel to objects[0].sharingModel when the junk entry is removed — a finding about the VALID object, not about the junk.

How the parsed path can produce one at all: it mostly cannot, and that is the point — these rules are pure (stack) to Finding[] (ADR-0019) and run on the raw path too, where objects is whatever the author's files deserialised to. An empty YAML list item is exactly null. A shape defect is the schema's subject, not reference integrity's, and object-graph.ts decides no severities and holds no rule ids by contract — reporting from there would also emit the same finding once per member for one bad entry.

Reproduction

On origin/main at 615fac3a0, before the change:

THROW validateObjectFieldRefs   { objects: [null] }            -> TypeError: Cannot read properties of null (reading 'name')
        at indexObjectGraph (packages/lint/src/object-graph.ts:159:30)
THROW validateObjectFieldRefs   { objects: [null, validObject] } -> TypeError: Cannot read properties of null (reading 'name')
        at indexObjectGraph (packages/lint/src/object-graph.ts:159:30)
THROW validateListViewFieldRefs { objects: [null] }            -> TypeError: Cannot read properties of null (reading 'name')
        at indexObjectGraph (packages/lint/src/object-graph.ts:159:30)

After, with the valid object beside it still judged:

OK validateObjectFieldRefs   { objects: [null] }              -> 0 finding(s)
OK validateObjectFieldRefs   { objects: [null, validObject] } -> 1 finding(s) [object-field-ref-unknown]
OK validateListViewFieldRefs { objects: [null, validObject] } -> 1 finding(s) [list-view-field-unknown]
OK validateDatasetReferences { objects: [null, validObject] } -> 1 finding(s) [dataset-field-unknown]

The reported positions are unchanged — objects[1].highlightFields[1], objects[1].listViews.all.columns[1], datasets[0].dimensions[0].field. The guard drops the entry from the GRAPH while each member's own loop keeps walking the raw array, so paths still count the junk entry and stay stable against the author's file.

What changed

• packages/lint/src/object-graph.ts — asArray filters non-records in both of its uses: stack.objects, and obj.fields one level down (fields: [null] crashed at the identical statement). The name-keyed map branch stops spreading a non-record value; the verdict for { a: 'junk' } is no-field-map before and after.
• packages/metadata-protocol/src/build-probes.ts — the object plane's catch { findings = [] } becomes a runtime-layer object_field_ref_rule_failed error (severity error) carrying the thrown message. A rule that throws never again reads as zero findings on a receipt whose checked.objects already counted the object. Probes still never fail the publish they verify.
• Tests: seam pins in object-graph.test.ts; one case per indexObjectGraph caller in the shared reference-integrity-suite.test.ts harness; build-probes-rule-failure.test.ts for the probe half. Changeset: @objectstack/lint patch + @objectstack/metadata-protocol patch.

Reverse verification

Each half was ablated from the committed state, with the mutation proved on disk (marker counts + blob equality against 615fac3a0) and the restore proved by blob hash and an empty git diff HEAD. Expected direction was red-on-revert for each half's own tests and no others; that is what happened.

The second line is the defect in one sentence: an empty list where a crash happened.

One gate found a real problem, and then a phantom fix for it

check:error-code-casing red-flagged the new test file's object_field_ref_rule_failed literals (ADR-0112 D1 wants SCREAMING_SNAKE). The code is D6c — build-probe diagnostics shipped inside a 200 receipt, the same vocabulary the gate already exempts build-probes.ts and packages/objectql/src/build-probes.test.ts whole for — so the per-literal adr0112-ok: mark is the narrower spelling of that exemption, and no gate script or ledger was edited.

Worth recording: the marks were first written as a comment block above the literal, and that read as green while suppressing nothing — the extra lines moved the literal out of the gate's recognition window entirely, so deleting the mark left the gate green too. Falsifying each mark individually caught it. They are now on the literal's own line (the spelling the gate's own self-test pins), and removing either one reds the gate.

What this does NOT fix — filed as #15552, not ridden here

The card's premise holds for the seam it names, but it is narrower than the class. Measured after this change, 13 of 42 AUTHORING_RULES entries still throw on { objects: [null] }, through five more unguarded readers of stack.objects:

• packages/lint/src/validate-widget-bindings.ts:465 — the fourth indexObjectGraph caller, which dereferences the entry in its aggregate-coherence pass BEFORE it reaches the seam, so this guard cannot reach it. That file is held by PR feat(lint): report a chart widget that selects no measures — or no dimensions (#15462) #15507, which is open and armed.
• Three inside the reference-integrity suite itself — validate-object-references.ts:142, indexObjectSearchTargets (validate-searchable-fields.ts:287, two rules), indexObjectFields (validate-page-field-bindings.ts:358, two rules) — so validateReferenceIntegrity({ objects: [null] }) still throws.
• filter-walk.ts:155 and six other single-rule readers.

⭐ That is stated in the suite test's own docblock as well, so the pin cannot be misread as covering the family entry point. The full inventory with per-rule throw sites and a control leg is in #15552, which is unassigned and is not addressed by this PR.

Verification

Exit codes captured before any pipe; verdict lines quoted as the tools printed them. Final commit for the gate re-run named below.

The gate family was derived after merging origin/main — the first derivation carried a ⚠️ STALE TREE banner naming 3 files the families derive from as changed, so it was discarded rather than reported. The re-derivation on the merged tree reports --repo 'objectstack-ai/objectstack' checked against this checkout's 'origin' remote — it holds. and yields the identical 48-command family.

The two exit-3s are NOT MEASURED, and are not read as green:

• pnpm check:dual-build-cjs-loads — Run pnpm build first. ⛔ This is NOT a pass: nothing was measured.
• pnpm check:type-check-debt — ⛔ This is NOT a pass and NOT a finding: nothing was measured

Both need a full monorepo build closure, which CI performs.

Re-run on the final commit ba6dd6e80, after the last two commits moved the tree — the ratchet families in particular, whose counts a late commit is exactly what moves: check:nul-bytes (OK (scanned 7520 text file(s) … no raw ASCII control bytes)), check:engine-double-contract, check:objectql-double-limit, check:error-code-casing, check:cross-package-test-inputs, check:test-source-alias, check:query-options-erasure (ratchet holds … none new), check:slot-lookup (ratchet holds … none new), check:type-check-coverage, check:doc-authoring — all exit 0. The two package test runs and pnpm lint above were also taken at ba6dd6e80.

Declared narrowings (CI runs the full farm regardless):

• One narrowing only: the full @objectstack/metadata-protocol suite (152 files) exceeds this container's 10-minute foreground cap under shared-lock contention. The 10 suites run above are its probe, publish-drafts and authoring-gate families — the ones this change can reach — plus the new file. CI runs the rest.
• pnpm lint was not narrowed: the whole-repo run is above, exit 0.

🤖 Generated with Claude Code

https://claude.ai/code/session_012zGPuVVX3deAx9LdjK8jCk

Generated by Claude Code